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APPLICATIONS AND SERVICES SUPPORTED BY A CLIENT-SERVER 
INDEPENDENT INTERMEDIARY MECHANISM 

FIELD OF THE INVENTION 

The present invention relates to client-server communication, and more 
specifically, to using an independent intermediary mechanism between a client and a 
server. 

BACKGROUND 

The World-Wide Web (WWW, W3, the Web) is an Internet client-server 
hypertext distributed information retrieval system. An extensive user community has 
developed on the Web since its introduction. 

Figure 1 is a block diagram of a prior art client-server system. The client A 110 
can access destination servers DS1-DS3 150-170. Similarly, other clients B and C, 120 
130, can access the destination servers DS1-3 150-170. Each destination server may 
provide different services, information, or other data to the user. 

On the Web everything (documents, menus, indices) is represented to the user as 
hypertext objects in hypertext markup language (HTML) format, or as Java, or 
JavaScript objects, or other data types. Hypertext links refer to other documents by 
their uniform resource identifiers (URLs). The client program, known as a browser, e.g. 
NCSA Mosaic, Netscape Navigator, runs on the user's computer and provides two basic 
navigation operations: to follow a link or to send a query to a server. Users access the 
web through these browsers. 

Users often access the web from multiple locations. Users may access the web 
from their office, at different locations at work, at home, or on the road. Libraries and 
Internet cafes make web access available on a walk-in basis as well. 

A user accesses a server by typing the URI of the server into the browser's 
address window. The browser then connects to the server corresponding to this URI. 
Another method of accessing a web site is by selecting the web site from the list of 
bookmarks. The list of bookmarks is resident in the browser in the user's computer. 
Thus, if a user wishes to have similar bookmarks on multiple computers, he or she must 
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manually copy the bookmarks and transfer them between the computers. This process 
is inconvenient. 

Furthermore, many servers use cookies to store information about the user. This 
information may include the user name, password, previous interests, etc. These 
cookies are also stored in the user's browser. Again, this means that if the user is 
accessing the Internet from multiple computers, the user's cookies have to be duplicated 
into multiple computers. This process is inconvenient. 

Many users have multiple accounts on different computer systems. For example, 
a user may have an account with a bank, an e-mail account, a personalized portal site 
account, and an account on an e-commerce server. Currently, the users must log into 
each of these accounts by remembering and providing his or her user name and 
password. For security, each of these user names and passwords should be different. 
Remembering different names and passwords is inconvenient to the user. Thus, a 
method for a simple log-in into various accounts from any computer would be 
advantageous. 

Most clients and servers support "forms" which allow the user to enter arbitrary 
text as well as selecting options from customizable menus and on/off switches. As 
more business is transacted on the Web, forms are proliferating. The forms may 
include forms for requesting further information, for ordering items from the Web, for 
registering for a Web site, etc. However, the user generally can not get a copy of the 
information filled into the form. The user can either print the page when the form is 
filled in, generating a paper copy, or rely on the server to respond in a manner that 
permits the user to make a record of the information entered in to the form. A method 
of tracking information filled into forms would be advantageous. Furthermore, 
vendors may respond with an order number or other useful information. The user can 
keep a copy of this page, which is generally only temporarily available, by printing it, or 
copying down the information provided. A method of attaching this vendor response 
to the original order information and making both available to the user would be 
advantageous. 

Furthermore, currently, the user has to fill out each of these forms separately. 
Generally, the forms request the same types of information, i.e. name, address, 
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telephone number, e-mail address, etc. The user has to enter all of this information for 
each form. This is repetitious and takes time. Additionally, if such information as 
credit card number or social security number requested, the user has to pull out the 
credit card and copy a long string of numbers. This makes errors likely. Furthermore, 
the user has to verify that a Web site that requests a credit card number or similar 
confidential information is of the appropriate level of security for the user to feel 
comfortable sending the information over the Web. An improved method of filling out 
forms would be advantageous. 

SUMMARY OF THE INVENTION 

A method and apparatus of accessing data through an independent intermediary 
mechanism (IIM) is described. The method includes displaying a frame including a 
user interface of the IIM, the frame framing a destination server display area (DSDA). 
The method further includes having one or more of the following functions provided 
by the EM: a home page, a history list, bookmarks, a one-click account log-in function, 
a transaction record accessible to the user, a forms database permitting new forms to be 
added to the forms database, a user profile, and automatic form-fill function based on 
the forms database and the user profile. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example, and not by way of 
limitation, in the figures of the accompanying drawings and in which like reference 
numerals refer to similar elements and in which: 

Figure 1 is a block diagram of a prior art client-server system. 

Figure 2 is a block diagram of one embodiment of the client-server system 
including the independent intermediary mechanism. 

Figure 3 A is a block diagram of one embodiment of the client-server system 
including multiple independent intermediary mechanisms. 

Figure 3B is a block diagram of another embodiment of the client-server system 
including multiple independent intermediary mechanisms. 

Figure 4 is a block diagram of one embodiment of the independent intermediary 
mechanism. 
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Figure 5 is a block diagram of one embodiment of the layout of the user interface 
of the independent intermediary mechanism. 

Figure 6 is a flowchart of an overview of using the independent intermediary 
mechanism. 

Figure 7 is a flowchart of one embodiment of the process of displaying 
information from a destination server through the independent intermediary 
mechanism. 

Figure 8 illustrates one embodiment of the user interface of the independent 
intermediary mechanism. 

Figure 9 illustrates another embodiment of the user interface of the independent 
intermediary mechanism. 

Figure 10 is a flowchart of one embodiment of the form fill functionality. 

Figure 11 is a flowchart of one embodiment of the learning process in the 
database. 

Figure 12A is a flowchart of one embodiment of adding accounts. 
Figure 12B is a flowchart of one embodiment of accessing an account through an 
auto-log-in feature. 

Figure 13 is a flowchart of one embodiment of the transaction management 
functionality. 

Figure 14 illustrates one embodiment of the listing of transactions. 
Figure 15A is a flowchart of one embodiment of selection of a home page or a 
bookmark. 

Figure 15B is a flowchart of one embodiment of using the bookmark 
functionality. 

Figure 15C is a flowchart of one embodiment of using the history functionality. 
Figure 16A-C are tables illustrating examples of redirecting references to DS 
through KM. 

Figure 17 is a table illustrating examples of making the IIM user interface frame 
persistent. 

Figure 18 is a table illustrating examples of accessing cookies from the EM. 
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Figure 19 is a table illustrating examples of preserving top frame or IIM frame 
integrity for DS. 

DETAILED DESCRIPTION 

A client-server independent intermediary mechanism is described. The 
independent intermediary mechanism (IIM) mediates information exchanged between 
a client and servers by having the client-server communication pass through the IIM. 
This allows the IIM to offer various services. For one embodiment, the IIM may be used 
to have a central web-accessible set of bookmarks. The IIM may further provide 
tracking of transactions on the web, providing a user-accessible transaction record. The 
IIM may further be used to fill in various forms automatically. The IIM may further be 
used to access multiple accounts, such as e-mail accounts, bank accounts, etc. with a 
single button. The IIM may further be used to store the user's profile, including 
passwords to various pages, etc. These and other uses of the IIM are described below. 

Figure 2 is a block diagram of one embodiment of the client-server system 
including the independent intermediary mechanism. Multiple clients A-C 210, 215, 220 
access multiple destination servers (DSs) 280, 285, 290, through the independent 
intermediary mechanism (EM) 250. Client A 210 is described as an example. It is to be 
understood that multiple clients are implemented in similar ways. 

Client A 210 accesses the IIM 250. For one embodiment, this occurs when the 
user of the client A 210 accesses the web site hosting the IIM 250. When the IIM 250 is 
accessed, a new client component (CC) 230 is established. The client component(s) 230, 
235, 240 and the server component 260 together form the DM 250. For one embodiment, 
the IIM 250 is located on a server accessed by the client A 210 through an Internet 
connection. For another embodiment, the EM 250 is located within the local Intranet of 
client A 210. For yet another embodiment, the IIM 250 is located on the client's own 
computer. 

For one embodiment, the client component 230 is established on the local 
computer of the client 210. For another embodiment, the client component 230 is on a 
server, or on a third computer system. The client component 230 is created in response 
to the client 210 connecting to the IIM 250. 
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The client A 210 has a connection to the server component 260 through the client 
component 230. For one embodiment, the client A 210 also establishes a direct 
connection with the server component 260. This direct connection may be used to 
communicate certain information directly between the server component 260 and the 
client A 210. The client 210 accesses the destination servers DS1-3 280, 285, 290 through 
the IIM 250. For one embodiment, all of the communication between the destination 
server DS1 280 and the client A 210 is routed through the AM 250. For another 
embodiment, certain communications are routed directly between the client A 210 and 
the destination server 280. For example, certain large images that do not invoke other 
images or other data may be routed directly in order to speed up processing. 

The number of client components 230, 235, 240 depends on the number of clients 
210, 215, 220 coupled to the server component 260 at any one time. For one 
embodiment, the server component 260 consists of multiple components that act 
together. A block diagram of one embodiment of the IIM 250 may be found in Figure 4, 
below. 

Figure 3A is a block diagram of one embodiment of the client-server system 
including multiple independent intermediary mechanisms 350, 360. Each IIM 350, 360 
is shown having a corresponding server component, 355, 365. For another embodiment, 
the server components 355, 365 may be located on a single server, or within a single 
EM. Having server components 355, 365 coupled together may serve multiple 
purposes. For example, if a single IIM 350 has too many users connected to it, the IIM 
350 may redirect users to a second IIM 360. For another embodiment, a user may log on 
to a local IIM 350, for speed reasons, and the local EM 350 may connect to the user's 
"home" IIM 360 to retrieve the user's data. For yet another embodiment, the user can 
connect to their "home" IIM 350, which is remote, and the "home" nM 350 may redirect 
the user to a local DM 360 and send the user's data to the local IIM 360. In this way, the 
user's connection to the nM 350, 360 may be optimized. 

Figure 3B is a block diagram of another embodiment of the client-server system 
including multiple independent intermediary mechanisms. In this example, a client 310 
is coupled to two IIMs 350, 360. Generally, the client 310 first connects to the first nM 
350. Then, through the user interface of the first EM, the client 310 connects to the 
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second IIM 360. This may be advantageous if, for example, the first IIM 350 and second 
IIM 360 provide different services. Thus, for example, one IIM 360 may provide 
additional account management features, while the other IIM 350 provides form-fill 
features. By connecting to both IIMs 350, 360, in series, the user has access to the 
features provided by both IIMs 350, 360. 

Figure 4 is a block diagram of one embodiment of the independent intermediary 
mechanism. The IIM 400 has three layers. The lowest layer of the IIM 400 is the core 
engine 410. The core engine 410 includes a server component SC and a client 
component CO The Server Component, for one embodiment, is resident on the server, 
and handles all remote actions. The Client Component, for one embodiment, is resident 
on the client's system, while the client is connected to the IIM 400. For one 
embodiment, the client component is automatically removed from the client's system 
when the client disconnects from the DM 400. The lowest layer also includes a Cookie 
Manager 413, for managing any cookies received from and being sent to the destination 
server. The use of such cookies is discussed in more detail below. Furthermore, the 
lowest layer may include a Activation Manager 416. The Activation Manager 416 
determines if information is being transmitted by the destination server. For one 
embodiment, the Activation Manager 416 further determines if information is being 
initiated by a user's action. Information transmitted between the DS and the client is 
instrumented by the IIM 400, as will be described below. The Activation Manager 416 
detects when the IIM 400 should review communication between the client and the DS. 

The second layer is the application /UI framework layer 420. The application /UI 
framework layer 420 establishes the basic user interface and IIM engine. The 
application/UI framework layer 420 creates a persistent frame for the IIM 400. For one 
embodiment, the application/UI framework layer 420 further includes an 
instrumenting manager 425, for instrumenting data flowing from the destination server 
to the client, through the IIM 400. This process of instrumenting is described in more 
detail below. 

The third layer is the applications layer. The applications layer includes multiple 
applications. The applications listed here are listed as an example, and are not a 
complete list. The applications layer, for example, may include a Navigation Manager 
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430. The Navigation Manager 430 permits a user to navigate from destination server to 
destination server using the IIM 400. The applications layer may further include a 
Transaction Manager 440. 

The Transaction Manager 440 tracks the user's transactions, stores them, and 
makes them available for the user's review. Transactions are interactions in which a 
user submits information to a destination server, for example to order an item, ask a 
question, or otherwise interact with the destination server. The Transaction Manager 
440 tracks the data submitted by the user, and any response from the destination server, 
and permits the user to access this information. 

The Account Manager 450 permits the user to log into a variety of accounts, from 
e-mail to stock trading accounts, using a single click. The Account Manager 450 further 
permits the user to add accounts to this list. The Form Manager 460 permits the user to 
fill out forms encountered on destination servers via a single click. This is extremely 
useful for users that transact business on the web, and often fill out identical forms 
many times. The Profile Manager 470 is the database of the user's personal information. 
This information may be edited by the user, and is used to fill in forms via the form 
manager 460. The Database Manager 480 manages the various databases of the HM 400. 

The Bookmark Manager 490 permits the user to manage bookmarks maintained 
within the IIM 400. Having bookmarks, URIs of pages the user wishes to save, available 
in the IIM 400 permits the user to access his or her bookmark list from any computer. 

The History Manager 495 permits the user to manipulate the history list of sites 
the user has previously visited. For one embodiment, the user can change the 
permanence of the history lists, for another embodiment, the user can delete certain 
sites from the history list. 

The Homepage Manager 497 permits the user to set a homepage that is 
displayed when the user initially connects to the server providing the IIM 400. 

As can be seen, the IIM provides multiple functionalities. A single IIM 400 may 
include all of the functionalities described above, additional functionalities, or some 
subset of these functionalities. The IIM's functionality may be extended with additional 
features. 
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Figure 5 is a block diagram of one embodiment of the layout of the user interface 
of the independent intermediary mechanism. The client browser application window 
510 is displayed by a browser, such as Netscape Navigator or Microsoft Internet 
Explorer. The client side display area (CSDA) 520 is the display area available in the 
browser application window 510. Most browsers have a toolbar and other displays 
within the browser application window 510. For one embodiment, the IIM is designed 
to minimize the area of the browser application window that is not the CSDA 520. 

The CSDA 520 includes a toolbar frame 530. Although the tool bar frame 530 is 
referred to as a frame, for one embodiment, the tool bar frame 530 may be implemented 
in a non-frame format. For one embodiment, the tool bar may be implemented as a 
separate window. For another embodiment, the tool bar may be implemented as part 
of the display, not as a frame. 

The CSDA 520 further includes a destination server display area (DSDA) 540. 
The DSDA 540 is the area in which all information from destination servers is 
presented. 

The CSDA 520 further includes a communications frame 550. The 
cornmunications frame 550 is for communication between the client side and server side 
of the EM. Generally, the communications frame 550 is hidden from the user's view. 
Thus, the user would not see the communication between the client component and the 
server component. 

Figure 6 is a flowchart of an overview of using the independent intermediary 
mechanism. At block 610, the user connects to the IIM through the client browser. For 
one embodiment, this is done by typing the address of the EM into the address window 
of the browser. For one embodiment, the ITM may be the preset homepage of the user, 
or a bookmark in the client browser. 

At block 615, the user connects to a destination server (DS) through the IIM. For 
one embodiment, this is done by typing the address of the destination server into the 
address window of the DM. For another embodiment, the user may select an address 
from a history list of previously visited sites, from a bookmark list in the IIM, or the 
destination server may be a preset homepage in the EM. The IIM records the DS in the 
history database. The history database tracks the web sites that the user has visited in 
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the past. Such a history database may be useful to permit backtracking, or to visit 
previously visited sites. For one embodiment, this history database is maintained for a 
fixed duration of time, or a user preset period of time. For another embodiment, tjie 
history database is maintained indefinitely. 

At block 620, the process changes the reference to DS to go through the IIM and 
load the information from the DS in the DSD A, maintaining the IIM frame. This is 
described in more detail below. 

At block 625, the IIM determines whether the user submitted information to the 
destination server. For one embodiment, the actual test is whether information that is 
"sensitive" or "of interest" is submitted to the DS. For example, if a user selected a 
radio button for the next display, the response would be "no" even though some 
information was submitted. For one embodiment, the answer to this query is yes only if 
information that is in the user's profile is submitted. For one embodiment, the answer 
to this query is provided by the user through the user interface. If the answer is yes, the 
process continues to block 630. 

At block 630, the user's communication with the DS is recorded in the user's 
transaction database. For example, if the user ordered an item from a destination server 
site, the form that was filled in by the user, including all of the information filled in, 
would be recorded in the transaction database. This transaction database is available to 
the user. The process then continues to block 635. If, at block 625, the answer was no, 
the process continues directly to block 635. 

At block 635, the IIM forwards the communication, i.e. the information 
submitted by the user, to the DS. This communication includes relevant cookies. A 
cookie is a packet of information sent by a destination server to a browser and then sent 
back by the browser each time it accesses that server. Cookies can contain any arbitrary 
information the server chooses and they are used to maintain state between otherwise 
stateless transactions. Generally, cookies are maintained in a user's browser. However, 
for one embodiment, the IIM maintains the user's cookies. This permits a user to log 
into a site, and have the appropriate cookies available, no matter from what web client 
device or client browser the user accesses the site. 
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At block 640, the process determines whether the destination server responded 
to the user's submission of information. For one embodiment, some destination servers 
respond, with a thank you page, other data pertaining to order number, shipping code, 
delivery date, etc., when information is submitted to them. If the destination server 
responds at block 640, the process continues to block 645. 

At block 645, the DS's response is recorded in the user's transaction database, 
and associated with the user's submitted information. Thus, when the user reviews the 
transaction, he or she can review the entire transaction, including the DS's response. 

At block 650, the IIM instruments the DS's response, stores any cookies returned 
by the DS, and forwards the response to the client browser. One embodiment of this 
process is illustrated in more detail in Figure 7, below. Tables of some results of the 
process of instrumenting are illustrated in Figures 16A-C, and Figures 17-19. 

At block 655, the process tests whether the user continues to browse through the 
AM. The user continues to browse, the process returns to block 615. Otherwise, the 
process ends at block 660. 

Figure 7 is a flowchart of one embodiment of the process of instrumenting data 
displayed from a destination server through the independent intermediary mechanism. 
For one embodiment, Figure 7 is a more detailed flowchart of block 650, in Figure 6. At 
block 705, the EEM receives a communication from the DS. For one embodiment, this 
occurs in response to a user contacting a DS through the IIM. 

At block 710, the process tests whether there is a cookie or multiple cookies 
associated with the communication. Cookies may be sent by the DS to the client, to be 
stored on the client browser. If a cookie is associated with the communication, the 
process continues to block 715. At block 715, the IIM cookie database is updated with 
the new cookie. For one embodiment, cookies sent by the DS to the client browser are 
handled through the HM. Thus, the IIM would store all of the cookies for a DS, and 
give the DS its cookies. This is advantageous because it permits a user to access a DS 
from any computer, and all of the user's cookies are immediately available through the 
DM. The process then continues to block 725. If no cookies were associated with the 
communication, the process continues directly to block 725. 
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At block 725, the process parses the code to find the next keyword. For one 
embodiment, keywords are tags in HTML, or known keywords in Java or JavaScript. 
Figures 16-19 illustrate some examples of keywords that may trigger this process. For 
another embodiment, keywords may be any triggering signal that indicates that an 
action may be performed. 

At block 730, the process tests whether a keyword was found. If no keyword 
was found, the process continues to block 735, and ends. If the communication has no 
remaining keywords, the document has been fully instrumented, and is ready for 
display to the user. For one embodiment, certain communications may have no 
keywords at all. In that case, this process would end after a single pass. For yet another 
embodiment, under some circumstances, the process may ignore certain keywords. 
Certain references are not altered in the communication. For example, references that 
call static images, images that do not communicate information to the user and do not 
have embedded references, may be of no interest. For example, if the keyword calls a 
large passive figure with multiple components, the process may ignore the entire figure, 
by tegg^g figure related communications, and exit out of this process even if keywords 
remain. By altering only those references that are of interest, the process may be sped 
up. If a keyword was found, the process continues to block 740. 

At block 740, the process tests whether the keyword is an attempt to access a 
cookie from the cookie database. If the keyword is an attempt to access a cookie, the 
process continues to block 745. At block 745, the access attempt is changed to fetch the 
cookie from the HM's cookie database. Some examples of this process are provided in 
Figure 18. For one embodiment, the HM's cookie database may access the client 
browser's cookie database in order to determine whether there are additional cookies 
on the client browser. For one embodiment, the IIM can, with the user's permission, 
copy cookies from the browser cookie database to the IIM. This simplifies moving from 
direct access of a DS to accessing a DS through the EM. The process then continues to 
block 750. 

If the keyword is not an attempt to access a cookie, the process continues directly 
to block 750. 
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At block 750, the process tests whether the keyword is an attempt to access the 
top frame or IIM frame. If the keyword is an attempt to access the top frame or IIM 
frame, the process continues to block^755. At block 755, the access attempt is changed to 
access the top area of the destination server display area (DSDA). Some examples of 
this process are provided in Figure 17. The process then continues to block 760. 

If the keyword is not an attempt to access the top of IIM frame, the process 
continues directly to block 760. 

At block 760, the process tests whether the keyword is a reference to the 
destination server. If the keyword is a reference to the destination server, the process 
continues to block 765. At block 765, the reference is changed to be fetched through the 
IIM. Some examples of this process are provided in Figure 16A-C. The process then 
continues to block 770. 

If the keyword is not a reference to the destination server, the process continues 
directly to block 770. 

At block 770, the process tests whether the keyword is an attempt to access data 
from the top frame or IIM frame. If the keyword is an attempt to access data from the 
top frame or IIM frame, the process continues to block 775. At block 775, the access 
attempt is changed to fetch data from the topmost frame of the DSDA. Some examples 
of this process are provided in Figure 19. The process then returns to block 725, and 
parses to find the next keyword. 

For one embodiment, the above process may be triggered by a user. For 
example, a user may select a link, activate a JavaScript function, or otherwise initiate 
communication between the destination server and the client. The same process may 
occur in response to a cookie being sent or received, or a keyword being found as 
described above with respect to Figure 7. 

Figure 8 illustrates one embodiment of the user interface of the independent 
intermediary mechanism. The user interface includes a browser toolbar 805. For one 
embodiment, the IIM may configure the browser such that the browser toolbar area 805 
is not displayed when the IIM is active. The display area 810 of the browser includes 
the IIM toolbar 820, a hidden communications frame 815, and the destination server 
display area 845. 
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The IIM toolbar 820 includes the known browser controls 825, such as back, 
forward, refresh, stop, etc. Additional browser controls 825 may be added. The toolbar 
820 further inclddes an address entry control 830, where a user can type a destination 
server address in order to access the DS. 

The IIM toolbar 820 may further include buttons, or other selection mechanisms 
that permit a user to configure and use the IIM. The buttons may include Home, 
selecting a user's preset homepage, etc. The homepage is preset using the Set Home 
button 852. The buttons may further include the Mall button, giving one-button access 
to shopping. The buttons may further include Tags 860, displaying a list of a user's 
bookmarks. Bookmarks are added by selecting the Tag Address while visiting a web 
site, or by selecting the Tag Address button 862, and typing the address of a location to 
be bookmarked. 

The buttons may further include Accounts 865, permitting single-button log-on 
to a variety of accounts. These accounts are added with the Add Account button 867, as 
will be described below. 

The buttons may also include a Transactions button 870, that permits a user to 
review his or her transactions. This is illustrated in the destination server display area 
845 of Figure 8. The Profile button 875 permits the user to enter his or her personal 
data. The Fill-Form button 880 permits the user to fill in a form using the personal data 
from the user's profile or by using information submitted previously using the same 
form. If a form is displayed on the destination server display area 845, and the user 
selects the fill-form button 880, the form is automatically filled in with the user's 
information. The Clear Form button 882 permits a user to remove the information filled 
into a form. This provides an additional level of security to the user. 

The Admin button 885 provides access to account administration services. For 
one embodiment, the Admin button 885 is only available to those users who are 
authorized administrators. For one embodiment, the Admin button 885 is only 
displayed if the user is authorized to access account administration services. 

The toolbar 820 further includes a Bye button 890, which logs off the user from 
the IIM. The toolbar 820 illustrated is exemplary. The content and organization of the 
buttons on the toolbar 820 may be changed without changing the invention. 
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Figure 9 illustrates another embodiment of the user interface of the independent 
intermediary mechanism. As can be seen, the user interface may be flexibly 
implemented. Certain features may be provided by one interface and not provided by 
another. Furthermore, the look and feel of the user interface may be altered. The user 
may, for example, access all of the IIM features through pull-down menus, such as the 
pull-down menu 935, or radio buttons instead of buttons. One skilled in the art 
understands other types of user interface changes that may be made without departing 
from the broader spirit and scope of the invention as set forth in the appended claims. 

Figure 10 is a flowchart of one embodiment of the form fill functionality. At 
block 1010, a document with a form is displayed. For one embodiment, this is a result 
of a user accessing a destination server location that includes a form. This form may be 
an order form, an information request form, or any other form that may be encountered 
on the Web. 

At block 1015, the user requests the form-fill function through the DM user 
interface. For "one embodiment, the user presses the form-fill button. For another 
embodiment, the form fill may be automated. For yet another embodiment, the user 
can select whether the form fill function is automatically engaged. 

At block 1020, the process determines whether the form is in the user's 
transaction database. The user's transaction database has records of previously 
accessed and filled-in forms for the particular user. The transaction database may 
maintain such records for a limited time, or the user may delete transaction records. 
Thus, merely because a user has been to a particular site previously may not mean that 
the form is in the user's transaction database. If the form is in the user's transaction 
database, the process continues to block 1040, otherwise, the process continues to block 
1025. 

At block 1025, the process determines whether the form is in the form database. 
The form database is maintained by the HM and includes "known" forms. Such known 
forms have associations between form control identifiers in the form and profile items. 
Thus, for example, a form control identifier that is labeled "name" may have a link to 
the "First Name Last Name" item in the user profile. If the form is known, the process 
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continues to block 1030. At block 1030, the form control identifiers in the form are filled 
in from the user profile. The process then returns to block 1055. 

If the form is not known, the process continues to block 1035. At block 1035, the 
form controls are identified, based on the name of each control. Each control name is 
associated with entries in the user profile. The process then continues to block 1030, 
and the data is filled into the form from the user profile. For one embodiment, block 
1035 is skipped. This type of "guessing" may be user enabled, or may be only 
attempted for forms that are similar to known forms. 

At block 1020, if the form was found in the user's transaction database, the 
process continued to block 1040. At block 1040, the process tests whether any data in 
the user profile has been changed since the transaction in the transaction database was 
recorded. Transaction records are dated, as are changes to the user profile. A user 
profile may be changed by the user, for example, to change a credit card expiration 
date, number, or home address. If a user profile change of a relevant field is dated after 
the transaction record date, the process continues to block 1045, otherwise, the process 
continues directly to block 1050. 

At block 1045, the changed information is filled in from the user profile. In this 
way, the user only had to update his or her records once, in the profile, and that change 
is carried through the EM. For one embodiment, this step may be skipped. For another 
embodiment, this step may be user enabled. 

At block 1050, the remaining form control identifiers in the form are filled with 
data from the transaction database. The process then continues to block 1055. 

At block 1055, the filled-in form is displayed to the user, and the user is 
permitted to edit the data in the form. The user, for example, may not wish to provide 
certain data to a destination server. The user may chose to erase such data. 
Alternatively, the form may request data that is not found in the user's profile. The 
user may chose to fill in such data. 

At block 1060, the user submits the form to the destination server. For one 
embodiment, the IIM stores the information submitted to the server in the laser's 
transaction database. This is illustrated in Figure 13 below. At block 1065, the process 



) 0070838A2.I_> 



WO 00/70838 



-17- 



PCT/US00/11792 



ends. For one embodiment, the user may optionally select whether to use the user 
profile, transaction database, or both, and in what order, for form fill functions. 

Figure 1 1 is a flowchart of one embodiment of the learning process in the 
database. At block 1110, a privileged user connects to the IIM. For one embodiment, 
this privileged user is an employee of the group maintaining the IIM. For another 
embodiment, this "user" is an artificial intelligence unit that is used to identify forms, as 
will be described below. Such intelligent recognition programs are known in the art. 

At block 1120, the privileged user accesses a destination server page with a form 
through the IIM. At block 1130, the IIM displays a user interface for cataloguing the 
form. 

At block 1140, the user maps each form control to an element in the user profile 
object. The user profile is set up to contain a large number of possible data elements. 
Each form control should have a corresponding profile element. If no profile element is 
found for a form control, that form control may be tagged as "form specific/' For one 
embodiment, multiple elements in the user profile may be associated with a single form 
control, or vice versa. 

At block 1150, other information about the form is added. This information may 
include such information as the address of the form, whether the connection with the 
destination server that serves the form is a secure connection, whether the form is of a 
particular classification, etc. 

At block 1160, the user submits the information to the EM. 

At block 1170, the DM updates the form identification and form description in 
the form database to include the information added by the user. For one embodiment, 
the updating is a periodic batch updating. For one embodiment, a single central form 
database is maintained. In that instance, the IIM's updating may include sending the 
new form to other IIMs. Alternatively, each IIM may maintain its own separate form 
database. For yet another embodiment, an HM may have a central form database, and a 
separate internal form database. This may be useful, for example, for an IIM 
implemented within a company which has the general form database for pages 
accessed outside the company, and a separate internal database for internal web page 
forms. 



.0070838A2_I_> 



WO 00/70838 



-18- 



PCT/US00/11792 



At block 1180, the process ends. Of course, the privileged user may enter 
multiple entries, and may start the process again at block 1120. 

Figure 12A is a flowchart of one embodiment of adding accounts. At block 12ip, 
the user connects to the IIM through a client browser. At block 1220, the user accesses a 
destination server through the IIM. For one embodiment, the user accesses the account 
log-in page of the DS. This may be, for example, the account log-in page of the user's 
bank, of a portal, or of any other DS. 

At block 1230, the user requests to add the account to the user's account 
database. Each user may have an account database, which includes a list of accounts 
the user can access with a single click. 

At block 1235, the process determines whether the user has submitted log-in 
information to the account log-in page. If the user has not submitted the information, 
the process continues to block 1240, and the user is prompted to complete the log-in 
process. For one embodiment, if the account log-in process includes multiple pages, the 
user may indicate the end of the log-in process by pressing a certain key, or through 
other means. The process then continues to block 1245. If the user has submitted all of 
the log-in information, the process continues to block 1245 directly. 

At block 1245, the account entry is added to the user's account database. The 
account log-in information and data of account entry creation are recorded. For one 
embodiment, further information may be recorded. For yet another embodiment, only 
the user's log-in procedure is recorded. 

At block 1250, the account information is submitted to the DS for login. At block 
1255, the process ends. 

Figure 12B is a flowchart of one embodiment of accessing an account through an 
auto-log-in feature. At block 1260, the user connects to the IIM. At block 1265, the user 
accesses the account auto-log-in feature using the IIM user interface. For one 
embodiment, this is done by the user pushing the account button. 

At block 1270, the user selects an account to log into. For one embodiment, the 
user may have multiple accounts. In that instance, the IIM displays the accounts that 
the user has. For another embodiment, if the user only has a single account, that 
account is automatically selected when the user accesses the auto-log-in feature. 
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At block 1275, the IIM retrieves login information from the user's account 
database. As discussed above, the user's previous account log-in is monitored and 
recorded. This information is retrieved at block 1275. 

At block 1280, the IIM sends the log-in information to the appropriate 
destination server to log-in the user. The account information includes the address of 
the DS. The IIM accesses the DS as a client, and sends the user's information. 

At block 1285, the IIM instruments the DS's response and sends it to the user's 
browser for display. As discussed above, the response is instrumented such that 
references of interest are routed through the IIM. The user can now use the account, as 
usual. At block 1290, the process ends. 

Figure 13 is a flowchart of one embodiment of the transaction management 
functionality. At block 1310, the user connects to the IIM. 

At block 1320, the user transmits information in a form to the destination server. 
For one embodiment, the user first accesses a destination server page including a form 
through the IIM. This form may be an order form, an e-mail form, or any other type of 
form. The user then fills in the form and submits it to the DS. For one embodiment, the 
user may use the form-fill method described above to fill-in the form. 

At block 1330, the process determines whether the user sent the user's e-mail 
address to the DS- The user may submit his or her e-mail address so the DS can send 
responses directly to the user's e-mail. For example, certain systems may send 
confirmation e-mails or alert notices to the user via e-mail. If the user submitted his or 
her e-mail address, the process continues to block 1340. Otherwise, the process 
continues directly to block 1350. 

At block 1340, the e-mail address submitted to the DS is altered. Specifically, the 
e-mail address is bifurcated, generated two e-mails. The first e-mail goes to the user's e- 
mail address, as entered. The second e-mail goes to the EM. The second e-mail 
includes in its address the IIM and the transaction tag that identifies the transaction 
number to which the e-mail belongs. This allows the IIM to handle the e-mail. The 
process then returns to block 1350. 
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At block 1350, the IIM records a transaction in the user's transaction database 
and associates the submitted information with the transaction. The transaction, for one 
embodiment, has a transaction number. , 

At block 1360, the IIM determines whether there is a response from the DS. If 
there is a response, the process continues to block 1370. Otherwise, the process 
continues directly to block 1380. 

At block 1370, the IIM records the response from the DS in the user's transaction 
database. For one embodiment, the destination server may respond to the user. This 
response is associated with the transaction record. In this way, the user may review the 
transaction record, including the response. 

At block 1380, further information is recorded about the transaction. For one 
embodiment, this information may include the date and time of the transaction, and 
other information. 

At block 1390, any notes, data, or e-mails received with the transaction tag are 
attached to tho transaction. This may occur at any time, while the transaction is being 
recorded, or after that. The user may attach any data to the transaction, and the IIM 
may automatically attach any e-mails received with the transaction tag. 

At block 1395, the process ends. 

Figure 14 illustrates one embodiment of the listing of transactions. The 
transaction list 1410 may be sorted by date, using a menu 1425. The transactions may 
also be sorted by type 1435. For one embodiment, alternative methods of searching 
transactions may also be implemented. For example, a user may search the transaction 
records for purchases from a certain destination server. 

Each transaction record may include one or more of the following: date 1420, 
transaction type 1430, and description 1440 of the transaction. The record may further 
include the place 1450, the location from where the transaction was recorded. The user 
may add and edit additional notes 1460. Furthermore, the user may also add 
attachments 1415 to the transaction record. For example, the user may attach e-mails, 
documents, video, or other types of data. For one embodiment, e-mails may be 
redirected through the IIM and automatically attached to the transaction. 
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The vendor response 1470 is also recorded. The information the user provided 
1480 during the transaction is also included in the transaction record. The transaction 
may further include the information whether the transactioirbelongs to one of the 
accounts 1490 in the user's account database. The user is permitted to delete selected 
transaction records using a delete button 1465. 

Figure 15A is a flowchart of one embodiment of selection of a home page. The 
user connects to the IIM at block 1505. 

At block 1510, the user accesses a destination server page through the EM. At 
block 1515, the process determines which option the user is selecting. 

If the user is selecting the add bookmark option, the process continues to block 
1525. At block 1525, the address of the page is added to the user's bookmark database. 
This database is accessible to the user, to permit the user to access various web sites 
without typing the address of the site. The process then continues to block 1530, and 
ends. 

If the user selected the set home page option at block 1515, the address of the 
page is set as the user's homepage. The user's homepage is called up when the user 
initially connects to the EM. For one embodiment, the homepage is preset. For another 
embodiment, the user may not alter the homepage, and the homepage is customizable 
but includes advertising. The process then continues to block 1530, and ends. 

Figure 15B is a flowchart of one embodiment of using the bookmark 
functionality. At block 1535, the user connects to the EM. At block 1540, the user 
requests access to the user's bookmarks through the IIM user interface. For one 
embodiment, the user requests the bookmarks by pressing the 'Tags" button on the 
user interface. 

At block 1545, the IIM generates a bookmark list from the user's bookmark 
database, and sends the list to the client browser to display. For one embodiment, the 
bookmark list is displayed in the destination server display area. For another 
embodiment, the bookmark list is displayed in a separate window, or a separate frame. 

At block 1550, the user selects a bookmark to access a destination server page. 
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At block 1555, the IIM fetches the page address corresponding to the selected 
bookmark from the bookmark database. The bookmark database includes the actual 
address of the bookmark. * 

At block 1560, the destination server page is fetched by the IIM. The data from 
the destination server is instrumented and is sent to the client browser for display. In 
this way, the user can access bookmarks stored in the IIM's bookmark database. The 
process then continues to block 1565, and ends. 

Figure 15C is a flowchart of one embodiment of using the history functionality. 
At block 1570, the user connects to the IIM. 

At block 1575, the user requests access to the history list through the IIM user 
interface. The history list includes the sites the user previously visited. For one 
embodiment, the history list is maintained for only a period of time, such as thirty days. 
For another embodiment, the history list is maintained indefinitely, and may be purged 
by the user. 

At block 1580, the IIM generates a history list from the user's history database, 
and sends the history list to the client browser for display. For one embodiment, the 
history list is displayed in the destination server display area. For another embodiment, 
the history list is displayed in a separate window, or a separate frame 

At block 1582, the user selects a list entry to access the destination server page. 
At block 1585, the IIM fetches the page address from the history database. The page 
address is referenced through the DM. 

At block 1590, the EM fetches the destination server page, instruments the 
communication, and sends the data to the client browser for display. At block 1595, the 
process ends. In this way, the IIM permits a user to access a variety of services through 
the EEM. 

Figures 16A-C show sample alterations of references from the destination server 
by the EM. Figures 16A-C illustrate changes to HTML, HTTP protocol, JavaScript, and 
Java. For one embodiment, this technique may be expanded to new languages and 
other types of interfaces. The data that is normally communicated directly between a 
Destination Server (DS) and client browser is altered by the EM, as shown by Figures 
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16A-C For one embodiment, some data may be transmitted directly between the DS 
and the client browser, without passing through the IIM. 

For one embodiment, the IIM performs a subset of the message modifications 
required for redirection and downloads the client component to the client's browser, 
which performs the remaining subset of message modifications on the client machine. 
Together these two subsets of message modifications provide a complete solution for 
using an independent intermediary mechanism between a client and a server. 

The modification of HTTP communication messages for redirection occurs on 
both the IIM and the client browser using the client component. The points at which the 
message modifications occur are called "HTTP control points". 

Figures 16A-C illustrate examples of HTTP control points that occur on the client 
browser and the IIM. For HTTP message documents, description of modification code 
covers the three programming languages that are most widely used today for HTTP 
communication: HTML, JavaScript and Java. For another embodiment, the ELM utility 
may be broadened to include HTTP control points in other programming languages 
used for HTTP message documents. For one embodiment, the protocol modified in the 
messages is defined by the HTTP specification standard. One skilled in the art would 
understand how to expand the technique described to different programming 
languages or message protocols. 

Figure 17 is a table illustrating examples of making the DM user interface frame 
persistent. The IIM prevents DS's from overwriting the user interface of the IIM. This 
permits the user to access the IIM regardless of what DS he or she is accessing. 

Figure 18 is a table illustrating examples of accessing cookies from the IIM. 
Generally, the destination server and destination server data on the client system access 
the cookie cache on the client's computer system. The IIM modifies the access 
mechanisms to access cookies from the IIMs cookie database. 

Figure 19 is a table illustrating examples of preserving top frame or IIM frame 
integrity for DS. Objects are often hung from the top frame of the client browser. The 
IIM changes the references to the top frame to create or access these objects to references 
to the top frame of DSDA. In this way, the objects are appropriately handled. 



0070838A2J,> 



WO 00/70838 



PCT/US00/11792 



Figures 16-19 list some sample alterations resulting from the code instrumenting 
described above. Alternative methods of altering the code may be used. One skilled in 
the art knows how to implement different changes. 

In the foregoing specification, the invention has been described with reference to 
specific exemplary embodiments thereof. It will, however, be evident that various 
modifications and changes may be made thereto without departing from the broader 
spirit and scope of the invention as set forth in the appended claims. The specification 
and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive 
sense. 
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CLAIMS 

What is claimed is: 

1. A method of accessing data through an independent intermediary 
mechanism (IIM), the method comprising: 

displaying a frame including a user interface of the IIM, the frame framing a 
destination server display area (DSD A); 

retrieving destination server data (DS data) for display from a destination server; 
maintaining a history list of past addresses of destination servers visited by the 

user. 

2. The method of claim 1, further comprising: 
permitting access to the history list through the user interface. 

3. A method of accessing data through an independent intermediary 
mechanism (EM), the method comprising: 

displaying a frame including a user interface of the EM, the frame framing a 
destination server display area (DSDA); 

displaying a homepage to the user, when the user initially connects to the EM; 

permitting the user to access a destination server from the KM; and 

retrieving destination server data (DS data) for display from a destination server. 

4. The method of claim 3, further comprising: 
the user selecting a page as the homepage. 

5. A method of accessing data through an independent intermediary 
mechanism (HM), the method comprising: 

displaying a frame including a user interface of the EM, the frame framing a 
destination server display area (DSDA); 

retrieving destination server data (DS data) for display from a destination server; 

maintaining an account list for the user, the account list permitting one-key log- 
in into a plurality of accounts on the account list. 

6. The method of claim 5, further comprising: 
displaying the account list in response to a display request; and 
logging on to an account automatically when the account is selected. 

7. The method of claim 6, further comprising: 
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displaying an account edit screen in response to an account edit request; and 
adding a new account, including an account location, an account log-in name, 
and an account password; and 

displaying the new account on the account list. 

8. A method comprising: 

accessing a destination server through an independent intermediary mechanism 
(IIM); and 

accessing a destination server site including a form; 
receiving a request to fill in the form; and 
filling in the form from a database in the IIM. 

9. The method of claim 8, wherein the step of filling in the form comprises: 
determining if the user has a transaction record including the form; and 

if the user has a transaction record including the form, filling in the form from 
the transaction database. 

10. The method of claim 9, further comprising: 

determining if the user has changed an item in a user profile that is used in the 
form; and 

if the user has changed data, filling in the item from the user profile. 

11. The method of claim 10, wherein said step of determining comprises: 
comparing a date of the transaction record with a date of changes in the user 

profile; and 

if the date of the transaction record is older, determining if the changes in the 
user profile are of a relevant record. 

12. The method of claim 8, wherein said step of filling in the form comprises: 
determining if the form is in the form database; and 

if the form is in the form database, filling in the form based on information in the 
user profile. 

13. The method of claim 12, wherein the forms database includes a plurality 
of forms, such that locations in the form mapped into elements in the user profile. 

14. The method of claim 12, wherein the forms database comprises multiple 
databases, at least one of the databases being centrally maintained. 



BNSDOCIO: <WO 0070838A2_I_> 



WO 00/70838 



-27- 



PCT/US00/11792 



15. The method of claim 12, further comprising the step of adding new forms 
to the form database, wherein the step of adding new form comprises: 

opening a new form at a new address; 

associating form control identifiers in the new form with labels from a user 
profile database; and 

storing the new form, the new address, and the associated form control 
identifiers in the forms database. 

16. The method of claim 12, wherein the form database is maintained in a 
central location, and administered by an authorized updater, such that an HM updates 
an internal form database from the central location. 

17. The method of claim 8, wherein the step of filling in the form comprises: 
determining if the form is in a transaction database, 

if the form is in the transaction database, filling in the form based on information 
in the transaction database; 

if the form is not in the transaction database, determining if the form is in a form 
database, 

if the form is in the form database, filling in the form based on information in the 
form database and in a user profile; and 

if the form is not in the form database, matching entries in the user profile to 
form control identifiers in the form, and filling in the form based on the information 
from the user profile. 

18. A method comprising: 

accessing a destination server through an independent intermediary mechanism 
(IIM); and 

receiving an indication to add a universal resource indicator (URI) of the 
destination server as a bookmark; 

adding the URI as a bookmark in the EM. 

19. The method of claim 16, wherein the bookmark is located within a user 
database on the IIM. 

20. A method comprising: 
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accessing a destination server through an independent intermediary mechanism 
(IIM); and 

when a user submits a form to the destination server through the IIM, 

recording a transaction entry in a user's transaction database; and 
associating submitted information and form with the transaction; 
wherein the transaction is available for review to the user through the IIM. 

21. The method of claim 20, further comprising updating a form entry in a 
form database in the IIM, based on the form submitted by the user. 

22. The method of claim 20, further comprising the step of updating a user 
profile based on the information submitted in the form. 

23. The method of claim 20, further comprising: 
determining if the destination server replied to the submission of the 

information; and 

if the destination server replied, 
recording the reply; and 
associating the reply with the transaction. 

24. The method of claim 20, further comprising the steps of: 

adding one or more of the date, time, and other information to transaction 
record. 

25. The method of claim 20, wherein the user can selectively turn on and off 
the transaction recording facility. 

26. The method of claim 20, further comprising when a user accesses a 
destination server including a form, 

determining if the user has a transaction record including the form; and 
if the user has the transaction record, optionally filling in the data into the 
form based on the submitted information in the transaction record. 

27. The method of claim 26, wherein the user selects the option of filling in 
the data from a user interface of the IIM. 

28. The method of claim 20, further comprising when a user accesses a 
destination server including a form, 

detennining if a form database includes the form; and 
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if the form database includes the form, optionally filling in the data into 
the form based on a user profile. 

29. The method of claim 28, wherein the user selects the option of fillingin 
the data from a user interface of the IIM. 

30. The method of claim 28, wherein the forms database includes a plurality 
of forms, such that locations in the form mapped into elements in the user profile. 

31. The method of claim 21, further comprising: 

adding new forms to the forms database by an authorized updater. 

32. The method of claim 31, wherein the step of adding new form comprises: 
opening a new form at a new address; 

associating form control identifiers in the new form with labels from a user 
profile database; and 

storing the new form, the new address, and the associated form control 
identifiers in the forms database. 

33. The method of claim 31, wherein the form database is maintained in a 
central location, and administered by the authorized updater, such that an IIM updates 
an internal form database from the central location. 

34. The method of claim 7, further comprising: 

registering information when the user logs on to a new account; and 
adding the new account to the account list. 

35. The method of claim 34, wherein the user can optionally enable or disable 
the registering of information. 

36. The method of claim 34, further comprising: 

requesting a user response whether to add the new account to the account list, 
and only adding the new account to the account list if the user responds affirmatively. 



0070838A2_I_> 



WO 00/70838 PCT/US00/1 1792 

1 / 25 




Fig. 1 (Prior Art) 



i 



BNSDOCID- cWO 0070838A2 I > 



WO 00/70838 



2/25 



PCT/US00/11792 




WO 00/70838 



3/25 



PCT/US00/11792 



intermediary 1 




tntermedlary2 
360 



Fig. 3A 



BMSDOCID: <WO 0O70838A2_l_> 




BNSOOCID: <WO 0070838A2J_> 



WO 00/70838 



5/25 



V 

4 

PCT/US00/11792 




lis 

£2 



— m ^ 



1 & 
1I§ 



s s 

iff 

&3 



*l 0 



i f s 



1 1. 
If' 



ii 

if 5 



< 



s 

CD 

s 

is 

c 

I 
i 



co si 
o 



Is* 
31* 



BMSDOCID: <WO 0O70838A2_l_> 



WO 00/70838 PCT/US00/1 1 792 

6/25 



Toolbar frame 530 



Destination server 
Display area (DSDA) 
540 




Communications frame 550 



Client browser 
application window 
510 




Fig. 5 



BNSDOCID: <WO 0070838A2.J_> 



WO 00/70838 PCT/US00/11792 

7/25 




User connects to MM 
through Client Browser 
610 




User connects to Destination server (DS) 
through KM and l!M records instrumented 
DS address In history database 
615 



5 



Change references to go through IIM and to 
load in DSDA, maintaining IIM frame 
620 








Record user's 






communication with DS 




— ► 


in user's transaction DB 






630 



IIM forwards communication 
to DS including relevant 
cookies 
635 






Record DS response in 


Yes 


user's transaction DB 




645 




+ 



Yes 



Fig. 6 




IIM Instruments DS's response, 
stores cookies returned by DS, and 
forwards to client browser 



BNSDOCID: <WO 0O70838A2J_> 



WO 00770838 



8/25 



PCT/US00/11792 




Parse code for next keyword 
725 



Fig. 7 




SDOCID: <WO 0070838A2J_> 



WO 00/70838 



9/25 



PCT/US00/11792 





NSDOCID: <WO 00708 38A2_I_> 



WO 00/70838 



11/25 



PCT/US00/11792 




Document with 
Forms is displayed 
1010 




No 



User requests Form-Fill 
Function through IIM Ul 
1015 




Identify form field 
names 
1035 



Fill In data from 
user profile 
1030 



Fill In changed 
Information from 
profile 
1045 

= — » 

Fill In remaining information 
aa In transaction DB 
1050 

* — 

Display filled In form to 
user, and allow user to edit 
form 
1055 

j 



User submits form 
1060 




Fig. 10 



WO 00/70838 12 / 25 PCT/US00/11792 



Privileged User 
connects to IIM 
1110 




Privileged user accesses page 
with forms on destination 
server through IIM 
1120 



t 

IIM displays user 
interface for cataloguing 

form 

1130 



* 

Privileged user maps 
each form element to an 
element in user profile 
object 
1140 



± 

Privileged user adds 
other, information about 
form 
1150 

I 

Privileged user submits 
information to IIM 
1160 



IIM updates fo 


rm 


Identification and 


I form 


description In for 


m OB 


1170 




f End 




.... 





Fig. 11 



BNSDOCID: <WO 0070838A2_L> 



WO 00/70838 PCTAJS00/1 1 792 

13/25 




User accesses a DS 
through account login 
page 
1220 



User requests to add 
account to account 
database 
1230 




Prompt user to complete 
login process 
1240 



Add account entry into 
user's account database, 

record account login 
Information and date of 
account entry creation 
1245 



Submit account Info to 
OS for login 
1250 




Fig. 12A 



BNSDOCID: <WO 0070838 A 2, L> 



WO 00/70838 



14 / 25 



PCT/US00/11792 




User accesses Account 
Auto-logln using III 
1265 



User selects account to 
log into 
1270 



IIM retrieves login info 
from user's account 
database 
1275 



IIM sends login info to 
appropriate DS to Jog In 
user 
1280 



IIM instruments DS 
response and sends It to 
user's browser for 
display 
1285 




Fig. 12B 



.0070838A2.t_> 



WO 00/70838 



15 / 25 



PCT/US00/11792 




User accesses a page 

through Intermediary 
1310 




User transmits 
information in the page 
1320 






After e-mail address to 




bifurcate such that 




responses go to user 




and to IIM with 




transaction tag 




1340 



Store Information on 
transaction 
1350 




Old 
respond to 
transaction? 
1360 




No K 



Add date, time, anc 


1 other 


information store 


id to 


transaction 




1380 




* 


Attach any notes. 


data. 


or e-mails receive* 


i wtth 


transaction tag 


to 


transaction 




1390 





/" End N 
I 1395 J 

Fig. 13 



BNSDOCID: <WO 0070838A2_I_> 



WO 00/70838 



16 / 25 



PCT/US00/11792 




WO 00/70838 



17 / 25 



PCT/USOO/11792 




User connects 
to MM 
1505 




User accesses a OS page 
through IIM 
1510 




Fig. 15A 



BNSDOCID: <WO 0070838A2J_> 



WO 00/70838 1 8 / 25 PCT/US00/I1792 




User connects 
to JIM 
1535 




I 



User requests access to 
bookmarks through Ul 
1640 



HM gen 
boo km a rl 
user's bookr 
sends to CS 
15 


aratesa 

c list from 
nark OB and 
I to dlaplay 
♦5 




f 


User selects a bookmark 
to access DS page 

1550 






HM fetches page URI 
from bookmark database 
1555 






ITM fetches DS page. 
Instrument data, and 
aends to client browser 
to display 
1560 



End "N 
C 1565 ) 

Fig. 15B 



INSDOCID: <WO 0O70838A2.l_> 



WO 00/70838 An , oc PCT/US00/11792 

19 / 25 




User requests access to 
history through Ul 
1575 



1IM generates a history 
list from user's history 
database and sends to 
CB to display 
1580 



1 


r 


User selects a list entry 
to access DS psge 
1562 




f 


IIM letches psge URI 
from history database 
1585 







IIM fetches DS page, 
instruments data, and 
sends to client browser 
to display 
1590 




Fig. 15C 



BNSDOCID: <WO 0070S38A2J _> 



WO 00/70838 * 



20 / 25 



PCT/US00/11792 



1 Original Code 

<base href^anyURL"^ 


f Altered Code 

<base 

href«"http://www.DS.com/myD< 
cument.htmr> 

<base href="anyURL"> 


1 Comments 

www.DS.com is the hostname 
> of the DS. The IIM inserts the 
first <BASE> tag line after the 
<HTML> tag and before the 
<HEAD> tag, and before any 
_ existing <BASE> tags 


<torm action=7actionURL"> 


SaveOrigAction( form, 
actionURL) 

<form action-" 

httpy/wwiy.!i»lconVredirect?act 
=nttpy/www.DS.com 
/actionURLV 


www.HM.com ts the hostname 
of the IIM and www.DS.com is 
the hostname of the DS. 
SaveOrigActionO is a 
Javascript function that saves 
the form's original action. 


<applet codebase=7codebase" 
code="appiet.class"> 


<applet codebase*" 
http^/vvvwJIM.corn/redirect?cb 

http^/Www.DS.corn/codebase" 
codea-apDiet.c«ass'> 


www.IIM.com is the hostname 
of the IIM and www.DS.com is 
the hostname of the DS. 


<frame src=7myFrame.htmr> 

other tags, e.g., <script>, 
<area>, <faver> . <imo> 


<frame 

src="http://www. IIM.com/redire 
ct?src=nttp://www. DS.com/myF 
rame.htmr> 


www.IIM.com is the hostname " 
of the IIM and www.DS.com is 
the hostname of the DS. 


Mink.href« "newLocatSn^^^^ 


setURLProperty ( link, -href, 
"newLocation* ) 


setURLPropertyO sets the 
value of the property href to the 
value 

"rittp^/www. IIM.com/redirect? ur 
l=http^/www.DS.com/newLocat 
ion*, where www.IIM.com is the 
hostname of the IIM and 
www.DS.com is the hostname 
of the DS. 


link.onclick = originalOnClick 

1 
1 
■ 

r 


function 

addNewLinkOnclick(link){ 
HnieoncltckOrig « 

linlconcfick; 
Hntcondick * 

newUnkOnclfck; } 

function newUnkOnclick(link)( 
it ( link.originalHref » null ) 
HnlcoriginaiHref - link.href; 
var newHref « 

getFullPathName( 
Hnk.originalHref ); 
indhref » 

ittpy/virwwJIM.corn/red!rect?ur1 
•newHrof: 

etum link.oncfickOriflflf ) 


getFullPathName() returns the 
full pathname URL of the 
HTML and www.IIM.com is the 
hostname of the IIM. The 
function addNewUnkOnclickO 
is called when the HTML 
document ts first loaded 
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Original Code 

documem.write(StringToWnte) 


Altered Code - 
writeDocument ( document, 
StringToWrite ); 


Comments 

wnteDocument() recursively 
modifies all HTTP control 
points that occur in 
StrinqToWrite 


window.open( newLocation ); 


openWindow ( window, 
newLocation ); 


openWindow calls 
u/mrinw ooenn with the 
argument 

-http://www.IS.corn/redirect7ur1 
=http-7/www.DS.com/newLocati 
on" 


form.onsubmit = 
onginafOnSubmrt 


function 

addNewFormOnsubmit(form){ 
torm.onsuDmiujng = 

form.onsubmit; 
form.onsubmit «= 

newFormOnsubmit; } 

function 

newronTWjnsuDmii v Torm j \ 
if (form.originalAction « null) 
{form.originalAction «= 
formactton;} 

var new Action « 

getFullPathName(form.originaJ 

Action); 

form. action m 

http://www.llM.corivredirect?urt 
=newAction; 

return form.onsubmttOrigQ]J__ 


getFullPathNameO returns the 
full pathname URL of the 
HTML document and 
www.HM.com is the hostname 
of the IIM. The function 
addNewFormOnsubmitO »s 
called when the HTML 
document is first loaded 


class java.net.Socket 


Extends java.net Socket and 
overrides various constructors. 


The extended method modifies 
the host and port arguments. 
The modified host argument is 
the hostname of the IIM. The 
modified port argument is the 
port of the IIM 


java.applet.AppletContext 


Extends 

java.appletAppletContext and 
overrides various constructors 


The extended method modifies 
the url argument The modified 
uri sends the HTTP request to 
the IIM with the full pathname 
of the original url as a query 
parameter 


class )ava.appiet. Applet 


Extends java.appleLApplet and 
overrides various constructors 


The extended method modifies 
the url argument The modified 
url sends the HTTP request to 
the 4IM with the full pathname 
of the original url as a query 
parameter 
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f Unq.nalCode | Altered Code 1 n^^Z , 


reterer, ^ ^ 

e.g. value = origDoc.htm 


reterer, 

http://www. DS.com/origDoc.ht 
m 


reterer value is replaced with 
the full pathname of the 
document's original URL 


content-type, ~ 
value = null 


content-type, 

e.g.. value « image/gif 


If the value of content-type is 
null, the IIM sets this header to 
a vaiue that describes the type 
of content contained in the 
document. 


refresh. 
e.g. 

5000; onqDochtm 


5000; 

httpj r /wyvwJS.corTV r redirect?ref= 

http://www.DS.com/origDoc.ht 
m 


IIM replaces the URL portion of 
the value of the refresh header 
with the full pathname of the 
document's original URL 


301, 302 status codes, 

e.g.. URI value « 

littp-.//www.DS.corTvbrigDoc.ht 
ml 


301. 302 status codes, 
URI value ■ 

http^/www.lS.corn/redirect?uri» 

http://www.DS.com/origDoc.ht 
ml 


www.IIM.com is the hostname 
of the IIM 


201, 303. 305. 307 status 
codes 

URI values 


201 . 303. 305. 307 status 
codes 

modified URI values 


See 301 . 302 status codes 
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target = "_top" 

for <a href>. <frame>. <form> 
and <base> tags 



Altered Code 
target = •DSFrameName" 



Comments 

where DSFrameName is the 
name of the DSDA top frame. 



target = "_parent" 

for <a href>, <f rame>, <form> 
and <base> tags 
Ba^ascript ^x^rtfij 



target = "DSFrameName" 



top. location Property » value 



setTopProperty ( 
currentWindow, 
locattonProperty. value ) 



where DSFrameName is the 
name of the DSDA top frame, if 
the current window evaluates 
to the DSDA top frame. 

setTopProperty sets a location 
property on the DSDA top 
frame with name 
locationProperty to have value 
value 



window.parent. 
locationProperty = value 



iava.apptetAppletContext.show 
Document( url, target ) 



setTopProperty ( 
window.parent, 
locationProperty, value ) 



newShowDocument < window, 

url, target ) 

{ 

java.apptet.AppletContext.show 
Document( uri, newTarget ) 



setTopProperty sets a location 
property on the DSDA top 
frame with name 
locationProperty to have value 
value if wrndow.parent 
evaluates to the top or IIM 
frame 

newShowDocument calls 
java.appletAppletContext.show 
Document where newTarget is 
the name of the DSDA frame H 
target equals *_top" or if target 
equals *_parenr" and window is 
the DSDA frame, "newTarget" 
is set to target* otherwise. 
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string = document.cookie 



document.cookfe = 
cookieString 



javax.servlet.http.Cookie 



string =s getCookie( window, 
document ) 



setCookie( window, document, 
cookieString) 



getCookie() gets the cookie s 
value from the IIM and assigns 

the value to string 

setCookieQ sends the value of 
cookieString to the IIM to be 
managed 




public class iSCookie 
implements Serial izable { 

private long _creationTime; 

public boolean hasExpiredOf 
// expiration function code ) 
1 



maintains the cookie's creation 
time and contains convenience 
routines that determine if the 
cookie has expired 



public class Cookies extends 
PersistentObject implements 
SeriaJizable { 

public String getCookie (URL 
urt){> 

public static Cookie 
parseCookie(String str) { > 

public void 

addCookie(ISCookie coo, URL 
ut)<> 

private boolean 

validCookie(ISCookie coo, URL 
uff){} 



extends the Java persistent 
object class, and saves in a 
user database the user-specific 
cookie information that the OS 
sent in the set-cookie header 
This class also finds the 
cookies in the cookie database 
that are valid for a certain URI 
based on well known Cookie 
rules and returns a Cookie 
string for a given URI. 
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| Original Code I Altered Code I Comments 









window, location = newLocation 


setLocation(currentWindow, 
window, newLocation) 


setLocation() sets the 
window.location to the value 
"http://www.IIM.com/redirect7ur 
l=http://www.DS.com/newLocat 
ion", where www.IIM.com is the 
hostname of the IIM and 
www.DS.com is the hostname 
of the DS. 


saveLocation = 
window.location 


saveLocation = 

getLocation(currentWindow, 

window) 


where getLocation returns 
window.location except when 
window is equal to the top 
frame, then it returns the DSDA 
top frame's location 


top.userProperty = value 


setTopProperty ( 
currentWindow, userProperty, 
value ) 


where setTopProperty sets a 
user property on the DSDA top 
frame with name userProperty 
to have value value 


window.parent.userProperty = 
value 


setTopProperty ( 
window.parent, userProperty, 
value ) 


where setTopProperty sets a 
user property on the DSDA top 
frame with name userProperty 
to have value value if 
window.parent evaluates to the 
top frame. 
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